1. Field of the Invention
This invention relates to the field of computer software, and, more specifically, to completing input/output transactions.
Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever. Apple, Macintosh, AppleTalk, AppleScript, and all Apple-based trademarks and logos are trademarks or registered trademarks of Apple Computer, Inc. in the United States and other countries.
2. Background Art
A computer interacts with and communicates with various peripheral devices (also referred to as input-output (I/O) devices) such as printers, scanners, video displays, keyboards, disk drives, modems, CD drives, etc. I/O devices convert information from one physical representation to another for processing and storage within a computer. Thus, I/O devices are the means by which a computer communicates with the outside world. The processing and storing of I/O device information occurs within the main memory or central processing unit (CPU) of a computer.
In modern computer operating systems, functions, operations and processes may be carried out through asynchronous interaction between client and server processes. For example, a client may be a high-level device driver (a software component that contains the computer code needed to use an attached device) and a server may be the software component that directly manages the physical device. Through a client process, the client requests a specific function, action, or resource of the server.
One aspect of such computer operating systems is to ensure that each client request completes and is only acted on exactly once (i.e., no request may be lost and none may be processed twice). For example, a request may complete normally or it may complete abnormally due to user action, a hardware failure, or a time-out (i.e., the specified time limit for the server to respond to the client request expired). The underlying operating system must also permit clients to terminate requests after they have been issued without regard to the precise state of the request (e.g., the request may not have been forwarded to the server, or may already have been completed when the client's request to terminate the request was received). Furthermore, in a multi-processing system, there may be multiple clients and servers executing on independent hardware processors (so called “symmetric multiprocessing”) that can initiate, process, abort, or complete a request, and the operating system must ensure that exactly one of these competing processes actually operates on the request even if it had been initiated, processed, or aborted on a different processor.
One prior art method to ensure process completion and single execution consists of the client setting a flag to indicate whether the server process should continue or be terminated. In such a method, the server must periodically examine the status of the flag.
Prior art methods do not precisely track client I/O requests resulting in two process paths of completion, one path from the client, and one path for the server. Further, the notification to clients (regarding completion of a request) and notification to the server (of a standard request or a request to terminate a standard request) is dependent on the type of request, and the procedure that implements and completes the request. Thus, when a request is initiated by a client, the client waits for the completion of the request and is not informed and cannot obtain the status of the request. For example, some implementations of the UNIX operating system has a client start and wait or sleep approach. In such an approach, a client request is initiated and then waits for the server to complete the request. The client enters a “sleep” mode until the request is completed. Alternatively, the Macintosh environment, when a client request is started, the client specifies the address of a subroutine to be called when the request is completed by the server. If no address is provided, the client process waits for completion of the process and performs no other functions.
In the prior art, the client is unable to pick and choose which processes to complete or wait for subsequent to initiating the request. Consequently, there is no defense against a process that is initiated and never completes (e.g., due to a hardware failure, time-out, etc.). Further, the various stages of completion of a client request are intertwined specifically to the implementation of the client request or the server response.